Programs written in high-level languages (C, C++, ADA, etc.) require data stacks to isolate the local variables of each function. Generally, for a given thread or process, there is only one stack (“call stack”) and it grows on each interleaving of functions, and then shrinks when a function terminates (return). The memory of a computer generally stores a plurality of stacks, one for each thread or process.
A problem frequently encountered with stacks is the overflowing or the space allocated to one of them, mainly because of programming errors (unlimited recursive loops, unexpected branches, etc.) or functional defects (incorrect analysis of the stack size, insufficient memory allocation, etc.). Overflows may also occur when using data the size of which is known only on compilation (constructions with non-constrained types, mainly in the ADA language).
When such an overflow occurs, a process being executed writes outside the memory area that is allocated to its stack, usually in the area allocated to the stack of another process. Such a problem is difficult to detect and to analyze when it shows up after a delay, when the process the stack of which has been corrupted is activated.
For reasons of optimization of the generated code, the stack overflow is not conventionally managed by compilers.
In the past, some ADA compilers stored in a generic register a maximum permitted value for the stack pointer and verified after the prologue of each function—and therefore just after stack allocation—that the stack pointer had not exceeded that maximum permitted value. This solution was costly in terms of execution time and did not provide complete protection against the risks of overflow. Moreover, it provided no assistance to the programmer in sizing the stacks so as to avoid overflow errors.
Another known prior art method for managing overflow errors consists in using the memory management units (MMU) generally present in modern central processing units (CPU). The principle of this technique consists in creating a guard space around the memory area allocated to the stack, that is to say a small space (usually of 4 kB) before and after the stack area, read/write access to which is prohibited. If the stack pointer overflows, the application attempts to read or write in this prohibited area and produces a page error (program exception). This technique has a number of disadvantages:                it necessitates an MMU, which is a costly hardware unit, is not present in all processors, and is notably absent in many “onboard” processors;        programming the MMU is costly and constraining (for this reason, this unit is usually deactivated for most application software);        the protection obtained is not absolute: for example, if the local stack of a function reserves a large quantity of memory that is not used, it is possible to pass over the guard space and to carry on in a space to which access is authorized although it is not allocated to the stack.        
It should furthermore be noted that MMU are not provided for such an application, which constitutes a kind of “trap”.
In order to assist with sizing stacks, it is also known to write a known pattern in the memory cells allocated to the stack. After execution of a test program, the memory is examined to determine at what “level” of the stack this pattern has been overwritten by write operations. This technique is costly to implement and can be applied only in the development phase. It cannot manage or even detect the overflow, but reduces the probability that they will occur by allowing memory allocation better suited to the real requirements of processes.